Libris Britannia 4/science library(b).zip/science library(b)/COMMUNIC/BULLETIN/0801B.ZIP/PHNXDOC.15

Text File | 1987-12-04 | 24KB | 597 lines

    PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

15.0 ADVANCED USES AND OPTIONS

            Before you read and try to use any features in this section,
            be SURE you have read and understand all of the previous
            sections! Please also note that the text formatting below
            is not the same as the rest of the documentation because of
            the large amount of information this chapter contains.

15.1 SECURITY LEVEL, ACCESS AND ALLOWED

    It is CRUCIAL for you to have a thorough understanding of the
    relationships between userlevel, allowed, access and overwrite.
    This relationship forms a basis for much of Phoenix's power and
    flexiblity and will be essential knowledge to configure future versions.

    Phoenix will only allow a maximum level of 9999 so please change
    any existing records and configurations which may be higher than that.
    If you have any specific questions, please be
    sure we answer them to your satisfaction and understanding (no question,
    no matter how 'elementary' is dumb or stupid) because any lack of
    understanding of this base concept will totally confuse you later
    when you add the knowledge of the other toggles, some of which are
    not user level dependent and behave differently with different levels!

    1: you should reserve a security level higher than your own, simply to
       put things that are not in use so you don't see them and forget
       that you disabled them.

    2: If you are going to have co-sysops, put the co-sysop level into
       config, and put yours above that as 'super sysop' otherwise, make
       the config level your own.

    3: If a user's level is lower than that of a menu command, he will not
       be able to use that command. The sysop level in config will enable
       sysop-only commands in read messages, like kill, move, public, etc.
       Unless you can trust a co-sysop with your checkbook, wife, life, etc,
       place certain commands above his level so only you can get to them.

                   In the rest of this discussion,
                   we will refer to co-sysop and up as sysop level.

    4: NO user level, including YOU will be able to see or change
       passwords, change security, lock or revoke file transfers,
       override the system's automatic locking of transfers,
       overwrite files, toggle the message system public only areas
       or include to/from, or read comments without specifically giving
       each user who should be able to,  permission to do so in his
       user record! (see below)

    5: COMMENTS-   (access or alt+f2)
       as was stated earlier, comments are now saved to message area #1
       as messages to the sysop-name in config. You must give yourself
       permission in one of 2 ways. The easiest is, once you have entered
       the main menu, press ALT F2 and you will have permission. This
       toggle is for any user that is online. There is a command in
       the user maintenance facility (sysop 5) to do so for others not online.
       The configuration for comments is very convenient now. As sysop with
       access (ALT F2), you will read all comments and have the sysop-specific
       commands in reading messages, [move,kill,undelete,etc].





      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

       THE ONLY REQUIREMENTS TO READ AND REPLY TO COMMENTS, IS THE
       PROPER USER LEVEL TO ACCESS AREA #1 (you configure that in the
       configure files system command) AND THE ACCESS PERMISSION (Z in the
       user maint. menu, or ALT F2 for someone online, including locally).
       ONLY SYSOP LEVEL will be able to delete comments or have access
       to the other sysop-specific commands. Non-sysop level with access
       will only be able to do harmless things like reply to comments and
       save them as messages to any base.   If there are other messages
       in area #1, if you allow regular users into area #1, they will only
       be able to read the messages that are to them or are public. They
       will not know comments exist in that area unless they have the
       access toggle set. We chose to do this, rather than create a special
       area, so you do not lose the #1 area to only yourself. re-configuration
       of that could be time consuming and a pain at best in an existing
       system.

       Sysop level without access will have all the normal sysop commands
       and abilities for regular messages but will not see comments.

       Alt F2 has NO other meanings within the system except ability to
       read comments (along with user level to access area 1) and is a
       factor in making SUPER SYSOP (you).

       Replys to comments will be saved as regular messages and you may
       choose the area to save to but if saved to one of the special
       areas, publiconly or includefrom, the message will take on the
       attribute of that area.

  6:  ALLOWED-  (alt+f1)

       This command has different levels of meaning within the system.

       SYSOP LEVEL:
       Assuming that NO menu command is set higher than sysop level,
       the ALLOWED toggle ALT F1 (or a command in user maint.) will give
       global access to everything in the system but comments and overwrite
       files.

       This toggle affects the ability to do the following (assuming that
       the user has the proper user level to access the areas in the
       discussion):

       IN THE USER RECORD DISPLAY:
          See passwords, file transfer lockout status, change security,
          see whether a specific user has any permissions for comments,
          overwrite files or whether he has this command,and the ability
          to change these items.

       IN UPDATE MESSAGE SYSTEM:
          Use the commands to change the public only status of an area
          or change the Include To:/From: in message headers for that area.

       UPDATE FILES SYSTEM is NOT affected by any of these toggles.

       IN THE MESSAGE SYSTEM ITSELF:
          Without this ability, the sysop level will NOT see message
          to:/from: in header for the specified area. He will, however,
          have the commands to kill, undelete, private ,
          but NOT the move command (in one of the special areas. He will
          have move for normal areas).



      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

          With this ability, the sysop level will see message header
          to/from, and will have the ability to move the message to
          another base.

          Those with the allowed toggle set, EVEN THOSE WITH LESS THAN
          SYSOP SECURITY LEVEL will see the to/from info, and will see
          the user number report in any message area he has userlevel for.
          Less than sysop level will, of course, not have access to the
          sysop-specific commands in the read msgs menus.


       THE ACCESS (alt f2) AND ALLOWED (alt f1) toggles will also affect
       fast and slow scan of messages and will determine what information
       is displayed. They also, along with sysop level create SUPER SYSOP.

  7:  OVERWRITE FILES-
       ANY user may be given permission to overwrite files. We recommend
       that this ability be given after careful thought to what files
       areas the user has access to, otherwise, it could be disasterous.

NOTE:  Although there is not a 'delete files' command, with overwrite
       permission, you may upload a file of the same name. the system will
       delete the old one after asking permission to do so, and you may
       abort the upload thereby effectively erasing a file without replacing
       it. This will ONLY occur WITHIN THE CURRENT FILES PATH. Duplicate
       file checking is disabled when a "yes" is given to the prompt
       requesting permission to erase the file.

We STRONGLY recommend that you create some fake users with various
permissions and experiment to see how the system responds before giving
any of your real users any of these permissions. Certain combinations
discussed above create Super Sysop which has total access to everything
in the system.

15.2  A LIMITS.BBS FILE TUTORIAL

       The limits.bbs file allows you to dynamically change the
       maximum daily time limit and logon limit for a particular
       userlevel.
       References to Daily and per Login times are set in config.

       Without this file, if you set Daily to 100 and per Login to 50,
       any caller will have up to 2 50 minute calls allowed per day,
       or any number of shorter calls totaling 100 minutes before
       he is disconnected with 'timelimit exceeded'. Should this happen
       he cannot log back in till after midnight when his time left is
       reset.
       With this file, you may specify different time limits for
       each user level. How this behaves is dependant on the number
       in the per Logon limit parm. This number (in limits.bbs)
       becomes the initial time-left value in his user record
       (his DAILY time limit).
       Syntax is:
        5,25
        7,80
        100,200
        Using the above examples, the first line is limited time.
        Since it is BELOW the per Login (50 min per login), that user
        level will only have 25 minutes total per login and
        25 min total for each day.





      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

        The second line has 80 minutes, so since its greater than
        per login (50 min), he will have 80 minutes total for
        the day with only 50 minutes that login.
        He may call back and will have
        the balance of how long he was on previously, subtracted from
        the 80 minutes.

        The third line has 200 minutes per day with 50 minutes per login.
        Now, if you place a '!' in front, his per login time is that
        time specified in limits.bbs WITH NO DAILY TIME LIMIT!
        So:

        !,100,200

        user level 100 will have 200 minutes PER LOGIN and NO daily
        limit ever!

        Advantages to this are:
          1: Sysop level could have no daily limit and no 'juggling' of
             Daily or per Login parms are needed to give sysop as much time
             as needed.

          2: Create a 'guest' account with a pre-determined password
             to allow limited use of your system. simply announce
             the 'username and password' (useful for business applications)
             and that caller will only have x time which will be reset
             each call so other callers using that account
             the same day will not have
             a lowered time limit penalty.
             eg:
             !,4,15
             will give this 'guest' 15 minutes per login and his
             user record time left will never penalize him.

      This may be repeated for as many user levels as you wish.

      An additional field has been included for those who wish to
      change the per logon limit by user level. syntax is:
       4,100,25
       10,100,40
       15,100
       25,200,100
       !,100,200       NOTE that the THIRD PARM MUST NOT BE USED WITH THE !

       In the above example, the first line for sec level 4 will give
       100 min daily time with 25 minutes per login. (remember that the
       per Login parm is still set to 50 minutes in config).

       Note no login time for sec level 15. that level gets 100 min / day
       using the default  time set by the per Login parm in config.

       Level 25 gets 200 minutes per day with 100 min per login.
       It is very important that if you use the '!' that you NOT have
       the login (third) parameter! remember that the login time is
       set to the value after the security level and there is no daily limit
       when using this flag.
       You may only omit the LAST parameter (optional login limit)!
       Do not omit the daily limit
       and use 2 commas instead. The system is not set up to handle that
       and unpredictable results WILL occur.




      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

       Schedule times are ALWAYS checked, and if need be, the login time
       is adjusted to allow for the schedule REGARDLESS OF THE EXISTANCE
       OF THE '!' FLAG.

15.3 ALIAS.BBS

     The ALIAS.BBS file search has been enhanced. You may have a name
     on each line as before, BUT if you are looking for AN EXACT MATCH
     of a first and last name, you may have BOTH names on the same line
     separated by a space,comma or semicolon. The maximum is TWO names
     per line.

     NOTE that the comma,space and semicolon are delimiters only and are
     tested for by Phoenix and are stripped and will not become parts
     of a name either in the file or in the entry of the names from the
     user.
     Ex:

     dr dos
     dr,dos
     dr;dos

      are all the same to Phoenix with dr being first name and dos being
      the last name. Two names on the same line only qualify for an exact
      match for both, NOT either one (dos dr will be allowed)!
      If you want to match either one, each name must be on a separate line.
      They do not have to be capitalized as Phoenix will format the names.
      This way, you can flag a certain name while allowing either first
      or last name combined with something else to pass.
      Ex:
      Dr Holloway
        This name will be allowed by Phoenix as long as either name is
        not on a separate line.
        Also, if someone signs on with dr. dos, in the above example,
        he will be allowed in because
        it is not an exact match (the period changes the first name).
        The period is allowed because many professionals like formality and
        correctness of abbreviation in their names. You may, however, not
        allow the period simply by putting
        dr.
        in the alias file.

15.4  OTHER USES FOR FILES.BBS AND FILES.CLR

     For those die-hard RBBS people, we have added the ability to
     create an RBBS-like files area. If you wish only one files area
     and want all files to reside in that area, then do so. simply
     use files.bbs as the "dir.dir" (or whatever it is) which will
     list the classifications of files listings. eg:
     files.bbs would have in it:

     1. pascal files
     2. communications files
          or
     pascal   the pascal language files
     comm     the communications programs.








      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

     the user can then press l;1 or l;pascal to see the files listings
     of that "area". the naming conventions for the list file will be
     <first name>+.* so, if he must select "1" then the filename will
     be 1.bbs  , or, if he must select "pascal" then it will be
     pascal.bbs. these files follow the same .bbs/.clr rules the normal
     files.bbs would.
     The disadvantage to this system is that the sysop MUST create a
     separate upload path (Phoenix will update the files.bbs otherwise)
     and the sysop must update the appropriate files listings manually.
     This type area may co-exist with other Phoenix-type
     areas. NEW AND MATCH WILL NOT WORK FOR THIS TYPE OF AREA! No error
     will occur, simply nothing will be shown for that area.

     AN INTERESTING SIDELIGHT to this is- you may place a "filename".bbs
     in any area, and leave it private. give that name to a trusted user
     and you may place private files for him in that listing and the
     chance of anyone else guessing the name or even knowing its there
     is minimal. This will not affect Phoenix's use of the files.bbs.
     Phoenix will not know about this file until the user accesses it
     and will forget about it after dumping the information to the user.

     There is no command or configuration needed to use this feature.
     It is a side effect of chaining the "list areas" command. Simply
     place the file in the appropriate path, and use it.


15.5 ADVANCED USES OF THE PHOENIX MENU SYSTEM PLUS (tm)

You may create your own menu system based on the .mnu command menus
that will use ansi colors, or simply your own unique style menus.
Note that a menuxx.mnu command file MUST be present for each
menu you create or it will not be used.

TO BE CREATIVE:

The menu system MUST have a file present called menu.sec.
this file can have up to 24 different security levels each
on a SEPARATE line. THESE LEVELS MUST BE IN DESCENDING ORDER!
These security levels will only describe the level of the text
menu you wish to send to the user who has that level
(see below for a better description).

Descending order helps Phoenix to speed comparisons with the users level.
Each security level will correspond with a menu name/level combination.
this means you may create up to 24 different menus for each section of
Phoenix. (24 main menus, 24 sysop menus, 24 files menus, 24 message menus,
24 of each of any of the 25 menus Phoenix now has available to you).
That is a bit extreme, but the capability is there if you want it.
You may create this menu level file with copy con, or your favorite text editor
that will save a STANDARD DOS TEXT FILE.

Ex:
a sample menu.sec has:
100
4

meaning there are two levels of menu files, security levels 4 and 100.
There can be up to 4 characters  for the seclevel 9999, which is the
MAXIMUM security level.





      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

expert levels of x1 and x2 will simply have what they see now with no changes.
They will only get the menu name and a commandline.
The menu0.mnu file MUST exist or Phoenix will not run at all!
These command files (menuX.mnu) are just that,
they tell Phoenix what commands do what,
at what levels, and make up the command line prompt as well as
the standard menus.

Expert x0 level, will be dumped the menu text files which must have their
names formatted a certain way. These files will follow the .bbs and .clr
extension rules just like other files. The key is in the first name of the
file.

Using the menu.sec example above and assuming the sysop is making
ansi files available,and 100 is sysop level, the menu text files
will be formatted this way:


COMMAND FILE          MENU TEXT FILE       ANSI MENU TEXT FILE
------------------------------------------------------------------

MAIN.MNU
{menu0.mnu}            M0-100.BBS                M0-100.CLR
                       M0-4.BBS                  M0-4.CLR

SYSOP.MNU
{menu3.mnu}            M3-100.BBS                M3-100.CLR

MMS.MNU
{menu1.mnu}            M1-100.BBS                M1-100.CLR
                       M1-4.BBS                  M1-4.CLR

FILES.MNU
{menu2.mnu}            M2-100.BBS                M2-100.CLR
                       M2-4.BBS                  M2-4.CLR

NOTE THAT THE MENU NUMBER MUST BE THE FIRST SERIES OF CHARACTERS!!
M stands for menu and the number after it (1 thru 25) is the menu
number, then a "-" and the  security level (up to 9999).
So, M5-100.BBS is a text file for menu 5 at security level 100.
Please note that you do not need
any of the high level menu text files unless you want them. You may have only
the lower level menus and have the utilities for sysop command for yourself
but it will be 'hidden' since its not in the lower level menu, but it WILL be
in the commandline if security level is correct.
If menu.sec is present, and you do NOT create a menu text file , Phoenix
will default to the .mnu files automatically.
Of course, if the .clr file is not present, the .bbs file is dumped and
if neither is present, the .mnu descriptions are used.

SOME POINTS TO REMEMBER:

    If the security level of the user is LOWER than the lowest
    security level in menu.sec, the standard menus are dumped.
    Since these are TEXT files (or ansi files), you may design your
    menus ANY WAY YOU WISH! The only limitation is that you should keep
    to the commands you have installed in each menu of Phoenix, but you
    may segment the commands into blocks with different color backgrounds,
    or any way you wish.





      PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987

    User sec. levels in between menu sec levels, say security of 6 in this
    example, will be dumped the level 4 menu. Phoenix will ALWAYS dump the
    next lower menu security level if an exact match is not found.
    Ideally there should be as many menu
    text files as you have DIFFERENT security levels in the command files.
    That way, the user gets to see only the commands he has access to.

    You do NOT have to match the limits.bbs file. That only defines
    a users time on the system, so you can have as many different
    security levels and times as you want in that file
    and they all will only see
    one menu unless they cross the next higher menu security level.

    You may have,for example, a new user get the standard Phoenix menus.
    Regular users can get the standard menus also, maybe with more
    commands available (as it can be with Collie 1.2). However, you can
    treat your more priveledged users who get the same commands as regular
    users but get more time to better looking and more artistic menus and
    have real ansi menus too! This can be for any level, you simply must
    have the corresponding file with a menu-security level name, and the
    security level listed in menu.sec for it to be displayed.

    You may also choose to have only one menu text file for all levels including
    the sysop level. In that case, the level 100 (or your highest)
    menu should be renamed to the level 4 (or your lowest) menu.
    If you dont want ansi, you only need to have one
    menu text file for each .mnu file, or, none at all,or just some,or
    use the standard Phoenix menus. If menu.sec is missing, even if the
    menu text files are present, only the standard menus will be used.

    ALL THE COMMANDS WILL STILL HAVE
    THEIR MINIMUM SECURITY REQUIREMENTS (AS DEFINED IN THE .MNU FILE),
    EVEN THOUGH THE COMMAND WILL SHOW IN THE TEXT FILE (if you choose only
    one menu per command file and put the command into the text file).
    IT WILL NOT SHOW ON THE COMMAND LINE AND
    IF THEY TYPE A COMMAND THEY DONT HAVE ACCESS TO IT WILL SIMPLY
    SAY "Sorry, that is Invalid".


    The main thing to remember is that the files you create are dumped
    with the SAME RULES as welcome1 or any of the other .bbs / .clr files.
    the .mnu files still determine all the criteria for commands and
    program flow. Just to re-state, Phoenix will search the levels found
    in menu.sec for a level that is EQUAL to or if its not there, LOWER
    than the security level of the user online. If one of these two
    criteria are found, the appropriate menu text file is dumped to him.
    If the user has a security level LOWER than the lowest level listed
    in menu.sec, the standard Phoenix menu will be used.
    If a level is found that satisfies Phoenix's test, the .bbs /.clr rules
    apply, that is, if ansi is enabled and ansi files are dumped, if the
    .clr file is not there, the .bbs file will be dumped. if NEITHER are
    there AND the criteria for menu.sec ARE SATISFIED,
    Phoenix will use the standard menu. A user will never go without some
    kind of menu.
    Also remember, x1 and x2 expert users will NOT be dumped ANY of these
    files as they only see command lines or just menu names.
    If something is not right, no error will
    occur, simply the wrong menu or no text menu will be dumped and
    Phoenix will default to its standard menu.